The present invention generally relates to technology for configuring a data backup environment.
Generally speaking, in a computer system, data can be corrupted by a storage system failure or computer virus, and data can be lost due to a user operating error. In preparation for such data losses, a computer system is designed to carry out regular data backups so as to be able to restore lost data.
In Japanese Patent Laid-open No. 2005-196618, there is disclosed a technique for carrying out a batch backup of a logical volume (hereinafter, data volume) in which data used by an application is stored. Japanese Patent Laid-open No. 2005-196618 describes a storage system storing a collection of data volumes (hereinafter, a “copy group”) slated to undergo a batch backup operation, the receiving of a backup indication in a copy group unit, and the backing up of data at the same point in time for all data volumes belonging to a copy group by suspending writing until the backing up of data in all data volumes belonging to this copy group is complete. When a restoration is carried out in accordance with this backup technique, the data of the respective data volumes is restored to the status of the same point in time.
Japanese Patent Laid-open No. 2004-252686 discloses a backup technique that utilizes journaling. Japanese Patent Laid-open No. 2004-252686 describes acquiring a snapshot (a logical image of a full backup or a differential backup) of a specific point in time of a logical group (hereinafter, “journal group”) constituted from one or more data volumes, and storing data written to a data volume in a journal volume associated to the journal group as a journal after acquiring the snapshot, and restoring the data of all the data volumes belonging to the journal group to the status of a specific point in time by applying a series of journals to a snapshot in the order in which they were written. This is one example of a technique generally called “Continuous Data Protection” or the abbreviation thereof “CDP”.
Japanese Patent Laid-open No. 2005-222110 discloses a remote backup technique for storing a journal in a remote site journal volume and carrying out data restoration at the remote site. Japanese Patent Laid-open No. 2005-222110 describes acquiring a snapshot of a journal group at a specific point in time, storing this snapshot in a remote site, and storing data written to the data volume in a remote site journal volume (a journal volume associated to the journal group) as a journal after acquiring the snapshot, and restoring the data of all the data volumes belonging to the journal group in the remote site by applying a series of journals to the snapshot in the order in which they were written. When this backup technique is used, the data of respective data volumes to be restored in the remote site are restored to the status of the same point in time.
Today, in order to make effective use of a company's management resources to enhance operational efficiency, most companies are constructing computer systems, which utilize an ERP package (Enterprise Resource Planning package) to integrate application programs (database management systems (DBMS), file systems, and so forth), which have been operated independently by each mission-critical department, to enable the respective applications to the operated associatively. For example, the various application programs (hereinafter, applications) operated by respective departments are sharing information by using the same storage system. Further, the entire computer system is carrying out processing more efficiently by enabling applications to utilize each others functions and make use of each others processing results. When applications are said to be associating here, it means that these applications are operating by using each others functions and making use of each others processing results.
When a failure occurs in a computer system in which mutually associated applications reside, the data consistency between the applications must be restored to the maintained status. That is, the various data that the respective applications are using must all be restored to the status of the same point in time.
Hereinafter, a group constituting a plurality of associatively operated applications will be called a “federated application environment”. Furthermore, there may be times when a single federated application environment is constructed from a plurality of federated application environments. For example, when a first federated application environment comprises a first application, and a second federated application environment comprises a second application, which opens a prescribed interface to the first application, the first application, which uses this interface, and the second application, which provides this interface, become mutually associated. This case can be treated as a single federated application environment, which is constituted by the first federated application environment and the second federated application environment.
In a federated application environment, in order to restore data consistency between applications to the maintained status, it is necessary to associate and backup data volumes used by respective applications to the same volume group, and at restoration, to restore the respective data volumes to the status of the same point in time. However, when an application, which opens an associative interface for providing a function to another application, resides within a federated application environment, there may be times when the administrator does not know the associative relationships of all the applications. In this case, the problem is that when the administrator constructs a backup environment, which is the environment for carrying out a backup (for example, the configuration of a volume group, and what kind of backup will be carried out in this volume group), it is impossible to assign the data volumes used by all the applications inside the federated application environment to the same volume group.
This problem will be explained in detail by referring to FIG. 23. This figure shows a federated application environment, in which AP1 (applications 1) and AP2 (application 2), AP2 and AP3 (application 3), and AP3 and AP4 (application 4) are respectively associated. In the same figure, AP2 and AP3 are managed by different administrators. AP2 and AP3 are associated by way of an interface opened by either one or both of AP2 and AP3. In a case like this, the AP2 administrator cannot recognize the association between AP3 and AP4. This is because AP3 processing is a so-called black box as seen by the AP2 administrator. Similarly, the AP3 administrator cannot recognize the association between AP2 and AP1. This is because AP2 processing is a so-called black box as seen by the AP3 administrator. For the same reason, the AP1 administrator cannot recognize the association of AP3 and AP4, and the AP4 administrator cannot recognize the association of AP1 and AP2. Thus, the fact that there are four associated applications, AP1, AP2, AP3, and AP4, which belong to the federated application environment, and the fact that the data volumes used by these four AP1, AP2, AP3 and AP4 are VOL1, VOL2, VOL3 and VOL4 is not known, and therefore it is not possible to assign VOL1, VOL2, VOL3 and VOL4 to the same volume group. Thus, the backup environments of AP1, AP2, AP3 and AP4, which belong to the same federated application environment, will differ.